iT邦幫忙

2026 iThome 鐵人賽

DAY 1
0
自我挑戰組

從 Page Fault 到 OOM:Linux 記憶體管理 30 天拆解系列 第 1

為什麼 Linux 記憶體管理值得拆 30 天

  • 分享至 

  • xImage
  •  

Linux 記憶體管理是我一直想系統整理的主題。平常我們很常看到一些看似簡單、但其實牽到很深的問題:為什麼 free 顯示記憶體快滿了,系統卻還跑得好好的?為什麼 process 的 VSZ 很大,RSS 卻不一定大?為什麼 container 明明設了 memory limit,最後還是被 OOM killer 殺掉?這些問題的答案,通常都藏在 Linux 對虛擬記憶體、page cache、reclaim、swap、cgroup 與 OOM 的設計裡。

這個系列想從 userspace 看到的現象一路往 kernel 裡面拆。前半段會先建立基礎模型:虛擬記憶體、page table、TLB、page fault、anonymous memory、file-backed memory,以及 copy-on-write。中段會進入配置與回收:buddy allocator、slab、page cache、dirty page、swap、LRU 與 memory reclaim。後半段則放在實務觀察:/proc/meminfovmstat、cgroup memory、OOM killer、PSI、THP、NUMA,以及如何用工具定位 production 上的記憶體問題。

我希望這 30 天不是單純列 kernel 名詞,而是把「觀察到的現象」拿來對照 kernel 實際做了什麼。例如 page cache 不是 Linux 偷吃記憶體,而是系統把閒置 RAM 拿來加速檔案 I/O;page fault 也不一定代表錯誤,它可能只是 demand paging 的正常流程。這些概念如果只背名詞,很容易在 production 上誤判;但如果能連回 kernel 的決策,就比較知道該看哪些指標、哪些數字可能誤導人、哪些行為其實是正常的 policy。

接下來每天我會盡量維持同一個節奏:先從一個實際現象或常見誤解開始,接著拆 kernel 裡的機制,最後回到可以怎麼觀察與 debug。第一個正式主題會從虛擬記憶體開始,因為它是理解後面所有問題的入口:每個 process 以為自己擁有一整片連續記憶體,但實際上,那只是 Linux 和硬體一起維持出來的抽象。


下一篇
虛擬記憶體:每個 process 看到的假象
系列文
從 Page Fault 到 OOM:Linux 記憶體管理 30 天拆解3
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言